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VEHICLE MANAGEMENT AND MISSION PLANNING 


SYSTEMS WITH SHUTTLE APPLICATIONS 
By Mission Analysis Branch 

1.0 SUMMARY 


This document presents a preliminary definition of a concept of an 
automated system that will support the effective management and planning 
of space shuttle operations. It is called the Vehicle Management and 
Mission Planning System (VMMPS). In addition to defining the system 
and its functions , this document identifies some of the software require- 
ments of the system and recommends a phased and evolutionary method of 
software design, development, and implementation. In accordance with 
this phased approach, the purpose of this document is to present the 
current concept in sufficient detail so as to elicit an initial round 
of constructive criticism from all interested parties. 

The proposed VMMPS (fig. 1-1 ) would provide the operational shuttle 
program with an automated centralized program planning capability. Al- 
though it will also possess the capability for real-time support, its 
primary functions will be the management and planning of shuttle opera- 
tions. To perform these functions it would be operated in an interactive 
mode by engineers and various levels of management. 

To define the VMMPS, this document identifies conceptually the shuttle 
operation planning functions, describes the required decision-making 
processes, and categorizes the organizational interfaces. Computer soft- 
ware subsystems required to support shuttle planning are postulated and 
correlated to the various planning functions. The presentation of these 
elements - planning functions, decision processes, organizational inter- 
faces, and supporting software - represents the shuttle operations plan- 
ning and management concept . 

The concept is composed of eight software subsystems supervised by 
an executive system. These subsystems are 

/ 
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a. Mission design and analysis 

b. Flight scheduler 

c. Launch operations 

d. Vehicle operations 

e. Payload support operations 

f. Crew support 

g. Information management 

h. Flight operations support 

Each of these is defined in this document. Of the eight subsystems, the 
first two, mission design and analysis and flight scheduler, already 
currently exist in initial prototype coded forms and are being used to 
support the MSC shuttle program office with traffic model analysis. The 
remaining six subsystems are in various degrees of preliminary definition 
but are generally just in the idea stage requiring future coordination 
with other MSC and MSA organizations for their interim and final defini- 
tion. 


In addition to presenting the proposed system, this report contains 
a discussion of the evolutionary software development philosophy that 
the Mission Planning and Analysis Division (MPAD) would propose to use 
in developing the required supporting software. Included in the dis- 
cussion is a preliminary software development schedule. 

As proposed in the development plan, existing software components 
will be used to construct the initial version of the prototype VMMPS. 
From this base, the more sophisticated total system will be developed 
in phases or directed evolutionary stages. An initial hard-and-fast 
VMMPS design will not exist; rather, the design will be generated and 
solidified in logical stages. The prototype system will be available 
for use at each stage of development. It will thus provide an early 
capability for performing some shuttle planning and analysis and will 
allow the evolutionary nature of the development to be most effective. 




VJJ 


VMMPS 

SOFTWARE 

OPERATIONAL ELEMENTS 

I I not yet defined 


Figure 1-1.- VMMPS concept. 
















2.0 INTRODUCTION 


The concept of a reusable shuttle has been accepted as a method to 
deliver man and cargo to earth orbit. Because of major differences be- 
tween it and past programs, however, the shuttle program will require 
new methods of planning and operating manned space flight missions. 

For instance, the shuttle should reduce payload delivery cost and 
increase space flight capability. Thus, the number of flights per year 
should increase. The projected rate of 20 to 50 flights per year will 
require a compression of the present mission planning cycle. The number 
of iterations or mission plans beginning from the preliminary mission 
profile through the reference trajectory and to the operational trajec- 
tory must either be eliminated or greatly reduced. Another difference, 
perhaps the most significant, that affects mission planning is the develop- 
ment of multiple payload missions. In the past each agency responsible 
for a particular payload has either developed mission plans in house or 
through their payload contractor. The combination of payloads on a 
single mission requires the integrated planning of the entire mission, 
and this cannot be done by independently planning individual missions 
and hoping for compatibility. Over 50 percent of all presently proposed 
shuttle flights require multiple payload deployment. Therefore, a cen- 
tral organization that is responsible for the planning of all shuttle 
missions seems essential. Figure 2-1 is a pictorial representation of 
the complexity of mission planning associated with five typical shuttle 
flights. On mission 1 are three payloads (PL). Two require a kick 
stage (KS) and the third is deployed by the shuttle. Each PL is de- 
veloped by a different contractor (CONT) in support of various agencies. 

The integration of these payloads into one mission plan and the repeti- 
tion of these types of missions indicate that one organization must be 
responsible for the development of these integrated plans. 


The use of kick stages is another major difference. From Uo to 
50 percent of the present shuttle traffic models require kick stages. 
The definition of the payload combinations (preliminary mission defini- 
tion) defines the kick stage requirements. A natural result of long- 
range flight schedules would be kick stage requirements. 


Another major difference is the reusability of the vehicles (orbiter, 
booster, RAM, and tug). The repeated use of major systems results in 
performance change that affects the mission planning (e.g., the I 

SP 

of engines changes with each burn). ■ This information must be taken into 
account during the mission planning for future use of these vehicles. 
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An apparent solution for coping with these complex management and 
planning problems is the use of a centralized mission planning system. 
This document gives a preliminary definition of such an automated manage- 
ment and planning system. Its objective is to propose this automated 
concept in sufficient detail as to elicit consideration and constructive 
criticism. 
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ACS 

CONT 

DOD 

FAA-ATC 

FOSS 

FSS 

g.e.t . 

GSE 

IMS 

I.O. 

I SP 

KS 

KSC 

LOS 

LRU 

MDAS 

MPAD 

MSC 

MSPS 

NASA 

OMSF 

OSSA 


3.0 SYMBOLS 

attitude control system 
contractor 

Department of Defense 

Federal Aviation Administration-Air Traffic Control 

flight operations support subsystem 

flight scheduler subsystem 

ground elapsed time 

ground support equipment 

information management subsystem 

input /output 

specific impulse 

kick stage 

Kennedy Space Center 

launch operations subsystem 

line replacement units 

mission design and analysis subsystem 

Mission Planning and Analysis Division 

Manned Spacecraft Center 

maintenance and system performance subsystem 
National Aeronautics and Space Administration 
Office of Manned Space Flight 
Office of Space Sciences and Applications 
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PL payload 

PSOS payload support operations subsystem 

RTCC Real-Time Computer Complex 

VMMPS Vehicle Management and Mission Planning System 

VOS vehicle operations subsystems 
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4.0 TOTAL SYSTEM OVERVIEW 


In general, the VMMPS is a non-real -time operation. Telemetry data 
from the actual flight in progress are not required. The overall concept 
originated from an attempt to automate (conceptually) the time-consuming 
mission planning and decision-making mechanism used for the Apollo pro- 
gram. The iterations between decisions and analyses must be decreased 
and the time between them must approach zero if an effective and efficient 
shuttle management program is to be instituted. The solution proposed 
by this document is that the required decision-making entity be supplied 
with software in support of the required functional areas. Then, through 
interactive capabilities, analyses can be performed and decisions made 
more rapidly. 

Another objective of the VMMPS is to eliminate reference trajectories, 
operational trajectories, flight plans, consumables budgets, and so on. 

Crew training and simulations would not depend on actual mission event 
times. This can be accomplished by the development of mission types. 
Preliminary analyses have indicated that the 400 flights of the proposed 
traffic model can be categorized into eight to twelve mission types. 

Crews could be trained and simulations performed according to these 
mission types. (The definition of crew here includes the experimenters, 
payload handlers, etc.) Parametric data could be generated so that the 
crew can do onboard mission planning within the constraints of the 
mission type defined. The differences between missions within these 
standard types are a result of requirements and on-orbit activities 
directly associated with the individual payloads or individual mission 
objectives. By classifying missions into types and then into phases, 
standardized profiles, crew training data, procedures, and techniques 
can be developed which can be used for most flights, thus, eliminating 
the need for much of the detailed mission-by-mission analysis that is 
now required and reducing the need for publication of individual mission 
documents . 

Figure 4-1 is a pictorial concept of this proposed system. It 
currently has no single counterpart; rather, its functions are being 
performed for Apollo and Skylab in a fragmented way by the various 
NASA panels. The concept of performing these functions in an integrated 
flight operations planning facility is new, but the role of such a 
system is a- direct and logical extension of the MSC mission planning 
and analysis activities currently being performed for Apollo and Skylab. 
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4.1 System Requirements 

4.1.1 General .- The VMMPS concept presented in this document is 
based on the assumption that the shuttle will be a transportation service 
for a variety of users. Each user will impose requirements related to 
his payload objectives. The VMMPS function, then, will consist of trans- 
lating the user requirements into specific missions, directives, schedules, 
operation plan, and instructions needed to carry out the shuttle trans- 
portation function. 

The user requirements on the shuttle will be defined in terms of 

a. Physical description of the payload, such as size, weight, 
shape, interfaces with cargo container or vehicle, and so on 

b. Desired orbital parameters and schedule requirements 

c. Ground testing, calibration, access, special handling, and 
launch checkout requirements 

d. Orbital support requirements 

e. Recovery and refurbishment requirements 

To accomplish the transportation function, the VMMPS must trans- 
form the multiple user requirements into 

a. Specific shuttle missions, traffic models, and flight schedules 

b. Flight trajectories, time lines, procedures, and onboard 
software 

c. Ground support plans, including vehicle, facilities, and 
utilization schedules 

d. Integrated launch schedules 

e. Crew training and scheduling plans 

f. Logistics operations plans 

This system will also allocate and schedule the necessary re- 
sources, identify and resolve conflicts, and form alternatives for 
management. This process may become a highly interactive exchange, 
requiring extensive modification of basic assumptions and objectives 
before a workable schedule is developed. 
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4.1.2 VMMPS requirements .- The basic VMMPS functional requirements 
that have been identified are 

a. Provide a central operations facility for planning and schedul- 
ing shuttle missions. Such a facility would provide 

1. Nominal support to detailed planning of shuttle missions 
within a time-constrained operations environment as 
established by flight densities 

2 . An analysis tool for investigating simulated operations 
flows and modifications to existing schedules and payload 
makeup 

3. Detailed trajectory analysis of specific mission or mission 
types as identified by mission loads and operations planning 

4. A means of assessing and evaluating changes in the status 
of any operations subsystem (contingencies) 

b. Provide a planning and scheduling tool capable of long-range 
time flow development on each of several operations subsystems 

1. Maintenance and turnaround schedules 

2. Mission loads planning 

3. Payloads integration flow 

4. Mission type analysis and mission launch date assignments 

c. Plan and simulate the ground operations activities to a detail 
necessary for effective mission scheduling and fleet manage- 
ment. (This might be a constant which represents turn around 
time) 

d. Provide sufficient inputs from remote operations facilities, 
such as launch or maintenance areas , for planning of shuttle 
missions. 

e. Provide cost analysis and tradeoff capability to be applied 
to various operations and missions plans. 

f. Be at all times capable of supporting multiple missions in 
series and parallel. 

g. Provide software and planning support for crew training and 
for onboard software verification. 
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k.2 System Operation Modes 

The present concept is that during high flight-rate periods (l-2 per 
month), a facility similar to that shown in figure U-l will exist and 
will be manned by individuals with the responsibility and authority to 
change mission objectives (affect what payloads are taken or retrieved on 
proposed flights), to change vehicle utilizations, establish launch dates, 
and so on. Whether this facility would be fully manned at all times or 
would only be manned during planning sessions has not been established. 

It would , however , be able to operate in any one of three modes . 

In the first operating mode the VMMPS would be able to satisfy pro- 
gram office preliminary planning requirements, that is, develop traffic 
models; perform cost trade studies on the number of vehicles, pads, etc.; 
define requirements for the kick stage or tug or both; and provide 
mission planning to the detail necessary to insure the feasibility of 
the missions defined in the traffic model. 

The second mode of operations would be more detailed and would 
include the following activities: 

a. Support payload development with mission planning information 

b. Define candidate mission types, requirements, and characteristics 

c. Develop and provide information necessary for training and 
simulations 

d. Establish mission sequence and priorities 

e. Develop long-range schedules 

f. Develop short-range schedules 

g. Assign vehicles for each mission 

h. Estimate resource, facility, and crew requirements 

i. Do cost analysis 

j . Evaluate payload compatibility with mission plans 

The third mode of operations, the most detailed, begins after the 
shuttle becomes operational. It would include not only the development 
of long- and short-range plans and schedules but the analysis of day-to- 
day variations of these plans as well. Some other activities of the 
third mode would be 
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a. Developing detailed mission sequences by phase 

b. Providing anomalies of mission types to simulation personnel 

c. Providing schedules for launch, landing, maintenance, payload 
development, mission support, FAA, and other areas of activity 

d. Defining onboard software (mission peculiar) requirements 

e. Rescheduling after anomalies 

f . Providing detailed cost analyses and budget forecasts 



4.3 System Description 


To accomplish the activity within each operational mode, the plan- 
ning system will interface with the required planning software through 
an executive system. As envisioned, the interfaces with other agencies 
and organizations would be through the Shuttle Program Office and the 
information management subsystem. Those interfaces are depicted in 
figure 4-2. Although all the software required to support the functional 
areas has not yet been completely defined, eight subsystems have been 
identified to various levels of detail and are discussed in section 5.0. 
Their conceptual roles and relationships and their functional and soft- 
ware interfaces are shown in figure 4-3. This figure is only an attempt 
to relate the elements of the VMMPS to various planning and analysis 
activities which the system is intended to support. The boxes in the 
upper half of the figure are meant to represent how related activities 
could be grouped into functional areas. The boxes in the lower half of 
the figure represent the major software elements of the VMMPS which will 
be required to support these activities. This figure is intended to 
illustrate the computational support role of the VMMPS and is in no way 
a recommendation of the organization or functional structure of the 
overall shuttle mission management and planning effort. For clarity, 
figure 4-3 is repeated before each subsystem discussion, with the 
appropriate subsystem and its primary interfaces outlined. 

The following items briefly explain the functions of each of the 
proposed software subsystems: 

a. Mission design and analysis subsystem (MDAS) - This software 
subsystem will be capable of several levels of mission design 
trajectory processing, depending upon the level of detail 
needed. It will be operable both in an online interactive or 
batch mode or in an offline batch mode. Its modules will be 
linkable for sequenced processing or will be singly executable 
for special, applications. This subsystem will be used primarily 
by the mission design element, and its primary software inter- 
face will be the information management subsystem (IMS). It 
will interface other software subsystems through the IMS. It 
will also be directable by the real-time support element for 
real-time computational trajectory support. 

b. Flight scheduler subsystem (FSS) - This software subsystem will 
be the integration element of the VMMPS and as such will be re- 
sponsible for the generation of long- and short-range mission 
planning and scheduling. It will also have the capability to 
generate launch, maintenance, payload integration, and mission 
load design schedules. Its prime software interfaces will be 
with the information, mission design and analysis, and vehicle 
operations subsystems. 
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c. Launch operations subsystems (LOS) - This subsystem will be. 
used to simulate the activities from the beginning of launch 
preparation to lift-off and the temporal relationship involved 
in pad refurbishment, scrub/relaunch cycles, and launch failure 
modes. The subsystem will also discern and respond to real- 
time conditions which require monitoring and statusing in the 
IMS. Interface will be with the IMS and the flight scheduler 
software subsystem. 

d. Vehicle operations subsystem (VOS) - The purpose of the VOS is 
to use test, design, and flight data to determine during mission 
planning what the predicted vehicle performance will be. This 
model will fulfill its purpose by making trend analyses on all 
appropriate subsystems. A large interface with maintenance 
activities will be required to insure update of those system 
parameters that affect mission planning. 

e. Payload operations support subsystem (POSS) - Long-range plan- 
ning of missions with several payloads will require logistic 
support information, development schedules of payloads, prob- 
ability of deliveries, interface constraints, priorities, and 
other considerations. An automated method of updating the 
status of several hundred payloads will be part of this soft- 
ware subsystem. Short-range planning will require the rapid 
evaluation of payload changeout , addition of new payload, or 
off-loading of payloads. Constraints associated with these 
functions will be modeled in this subsystem. The subsystem 
will also support the payloads officer in real time when he 
needs to evaluate candidate flight schedules in terms of re- 
trieval and refurbishment of payloads. 


f. Crew support subsystem (CSS) - The purpose of the CSS is to 
provide the VMMPS with information regarding crew status to 
insure that the shuttle flight schedule is compatible with 
crew resources and constraints. The CSS primarily interfaces 
with the flight scheduler subsystem. 

g. Information management subsystem (IMS) - This will be a dynamic 
storage and retrieval system with multilevels of data protec- 
tion. It will maintain formatted output storage of results 
from the other software subsystem operations and storage for 
basic data describing all aspects of the shuttle operations. 

The IMS software will allow liberal questioning and data re- 
trieval from numerous remote terminals. It will have complex 
interfaces and automatic linkage with all other subsystems for 
status, storage, and input supply to those subsystems by the 
various users. 
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h. Flight operations support subsystem (FOSS) - This software sub- 
system will provide contingency control and computational support 
plus real-time status and monitoring of flight operations. It 
will also provide rapid response to failure and contingency con- 
ditions in the launch operations or vehicle operations. Its 
prime software interfaces will be the real-time status and re- 
sponse files of the IMS and the detailed processors of the 
mission design and analysis subsystem. 




FIGURE 4-1. SHUTTLE MANAGEMENT AND PLANNING ROOM 





























FIGURE 4-2. VEHICLE MANAGEMENT AND MISSION PLANNING INTERFACES 
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VEHICLE MANAGEMENT AMD MISSION SYSTEM UTILIZATION 



SHUTTLE PR OG RAM OFFICE 


• Defines payloids 

• Estiblishs priorities 

• Approves lonq range plans 

• Makes budget related decisions 

• Provides user Interface 



OTHER PROGRAM OFFICES 
® • Provides Interface, direction 

and coordination for other 
space program supported by the 
Space Shuttle 


r: 



FLEET MANAGEMENT 


• Maintains VMMPS data base 

• Defines mission objectives 

• Constructs flight schedules 

• Integrates operations support 
plans 

• Monitors and controls operations 
progress 

• Analyzes and forecasts operation 
costs 

• Integrates logistics planning 
and control 

• Determines resource and fleet 
utilization 

• Forecasts operations support 
requirements 



[ MISSION DESIGN 


• Performs mission evaluation 

• Evaluated the flight schedule 
relative to trajectory consider- 
ations 

• Designs Individual missions 

• Performs trajectory and maneuver 
analysis 

• Hrfrr**ias the mission design 
data base 

■ Provides real-time contingency 
flight support 

• Generate crew training data 

• Generate real-time support data 

• Define and Verify onboard software 

• Develop flight procedures 

• Determine network, ATC, and land- 
ing requirements 



ORBITAL OPERATIONS 

• Maintains log of freefly- I 

Ing payloads 

• Develop payload related 
flight procedures 

• Insure that flight schedules 
are properly servicing exist- 
ing free flying payloads 

• Evaluate compatibility of 
Inflight payload operation with 
mission plan 

• Predict payload ground support 
requirements 

• Monitor f reef lying payload status 

• Evaluate schedule change on crl- i 
tlcal payload. support requirements! 


REAL-TIME SUPPORT 

* Provides flight contingency 
support 

* Interfaces with ATC 

* Supports experiments and 
payload 

’ Supports tuq operations 
' Scientific data reduction 


KREW OPERATIONS 

’ Makes crew assignments 
' Coordinates crew training 
requirements 
' Evaluates flight plans and schedule*! 

relative to crew considerations 
' Develops crew procedures 
* Evaluates Impact of schedule 
changes on crew requi r ements 


PAYLOAD OPERATIONS 

’ Evaluates payload timeline 
compatibility with fllqht’ 
schedules 

’ Evaluates payload compatibility 
with mission plans 

' Assesses payload interchange- 
ability and modification 

* Monitors and predicts payload 
status 

* Maintains payload related data 
base 

* Predicts payload servicing re- 
quirements 

* Establishes experiment priori- 
ties 


VEHICLE OPERATIONS 

• Performs subsystem performance 
prediction and trend analysis 
relative to flight planning 

• Maintains the Vehicle Log 

• Monitors and predicts vehicle 
status 

• Evaluates vehicle configuration 
compatibility with mission plans 

• Assigns vehicles to specific 
flights 

• Evaluates Impact of flight sche- 
dules on vehicle operations 


LAUNCH OPERATIONS 

• Evaluate launch consid- 
eration compatibility with 
flight schedules 

• Provides prelaunch timelines for 
fleet planning purposes 

• Evaluates Impact of “on pad" 
mission changes on launch 
schedule 

• Evaluates effect of launch 
holds 

• Insures that prelaunch and 
launch constraints ire con- 
sidered In plans 

• Provides current and pre- 
dicted launch operations 
status 


MAINTENANCE OPERATION 

• Predicts turnaround tlme- 
lines for fleet planning 
Evaluates Impact of maintenance 
requirements on flight schedule 
Evaluates impact of schedule 

• on maintenance operations 
Maintains maintenance data base 
Perforins cost trade studies re- 
lated to maintenance for flight 
scheduling decisions 



FIGURE L-3. VEHICLE MANAGEMENT AND MISSION PLANNING SYSTEM 


Planning Function; 
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5-0 SUBSYSTEM DESCRIPTION 


This section describes each of the distinct subsystems currently 
envisioned for the VMMPS. The subsystem breakdown used is not intended 
to imply equal levels of importance , size, or degree of utilization. 

In fact, the primary individual subsystems are the flight scheduler, 
mission design and analysis, and information management subsystems.* 

The launch operations, vehicle operations, payload operations, and crew 
support subsystems are intended to provide the overall planning elements 
01 tne fll 6ht scheduler subsystem with sufficient information to accu- 
rately predict operations status. The predictions will be used in the 
development of the long-range and short-range launch schedules. The 

su PP ort subsystem is the real-time support element of the VMMPS. 
The FOSS is an integral part of the VMMPS, so that the planning can be 
coordinated with the real-time operations. The planning of orbital 
maneuvers of a kick stage may require real time support and therefore 
must be evaluated before launch commitment. Actual real-time payload 

CO + n i\T nC " eS Wl11 alS ° affect the upcoming plans and must be integrated 
with the planning function. 
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SHUTTLE PROGRAM OFFICE 


• Defines payloads 

• Establish* priorities 

• Approves loop ranne plans 

• Makes budget related decisions 

• Provides user interface 


FLEET MANAGEMENT 

* Maintains VWIT'S data base 

* Defines mission objectives 

* Constructs fliqht schedules 

* Integrates operations support 
plans 

* Monitors and controls operations 
progress 

* Analyzes and forecasts operation 
costs 

* Integrates loql sties planning 
and control 

* Determines resource and fleet 
utilization 

* Forecasts operations support 
requirements 


NIS$10H Of SIAM MO MALVS15 SUtSt$T£M 



OTHER PROGRAM OFFICES 
® • Provides Interface, direction 

and coordination for other 
space proqram supported by the 
Space Shuttle 


n 



[ MISSION DESIfiN 


• Re»-foms mission evaluation 

• Evaluated the flight schedule 
relative to trajectory consider- 
ations 

• Designs individual missions 

• Performs trajectory and maneuver 
analysis 

• Maintains the mission design 
data base 

• Provides real-time contingency 
flight support 

• Generate crew training data 

• Generate real-time support data 

• Define and Verify onboard software 

• Develop flight procedures 

• Determine network, ATC, and land- 
ing requirements 



ORBITAL OPERATIONS 

* Maintains log of freefly- 
Ing payloads 

* Develop payload related 
flight procedures 

* Insure that flight schadules 
are properly servicing ealst- 
Ing free flying payloads 

* Evaluate compatibi 1 Hy of 
Inflight payload operation with 
mission plan 

* Predict payload ground support 
requirements 

* Monitor freeflying payload status ! 

* Evaluate schedule change on crl- j 
tlcal payload support requirements 



KREM OPERATIONS 

* Makes crew ass 1 gments 
1 Coordinates crew training 
requi rements 

1 Evaluates flight plans and schedule! 

relative to crew considerations 
1 Develops crew procedures 
1 Evaluates Impact of schedule 
changes on crew requirements 



• Evaluates payload timeline 
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5.1 Mission Design and Analysis Subsystem (MDAS) 

5.1.1 Introduction .- By the time the shuttle becomes operational, 
much of the detailed trajectory design and analysis work for the standard 
shuttle missions will have been accomplished. This will mean that much 
knowledge about the vehicle, its behavior, and detailed plans for the 
standard shuttle mission will have been accumulated. Nominal mission 
plans for the standard shuttle missions will have been generated; the 
most common mission phases and activities for the standard shuttle 
missions will have been identified, and procedures for accomplishing 
these activities will have been developed and standardized. The soft- 
ware (onboard and ground) required to support these activities will be 
available for training flight crews and ground support teams. For most 
shuttle flights, then, the mission planning activity will become one of 
arranging these standardized shuttle activities or phases into a mission 
plan which will meet the mission objectives while minimizing the penalty 
from constraint violations. 

The overall efficiency of the shuttle program will be increased if 
mission specialization can be minimized. Therefore, every attempt should 
be made to force conformity to standard mission types, even to the 
extent of reducing the efficienty of a particular flight or canceling a 
flight and rescheduling its payloads. A few missions, however, may pose 
special operational requirements for the mission planner, and may not 
conform to any mission type. For such missions, the mission design 
process will be much more like that currently performed; even so, these 
missions will still have some phases in common with the standard types 
and can thus be planned in a more timely manner than is currently 
required. 

5-1-2 Objective .- For the VMMPS concept developed in this report, 
the MDAS is the primary trajectory design element. Its objective will 
be the integration of a significant portion of the software required for 
trajectory design, evaluation, and analysis into one software subsystem 
compatible with the total VMMPS. The subsystem is expected to 

a. Reduce the overall mission planning cycle time 

b. Reduce the number of formal organizational interfaces required 
during mission planning 

c. Reduce the paper work and number of formal reports 

d. Permit concurrent consideration of mission, vehicle, payload, 
crew, and ground support requirements during the mission 
planning process 
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e. Permit concurrent consideration of more than one trajectory 
design to satisfy a given set of objectives 

f. ' Reduce the alternate mission planning effort 

g. Reduce the contingency analysis effort 

h. Provide a general engineering analysis capability (related to 
space flight) which will be readily adaptable to other programs 

5*1*3 Functions . — The function of this proposed subsystem will be 
to provide the VMMPS with all the trajectory design and analysis capa- 
required to support shuttle mission planning. The complexity of 
the computational support required will, of course, depend on the phase 
of mission planning underway in the VMMPS. As currently envisioned, the 
MDAS will be able to support at least . the following three levels of 
mission planning (fig. 5-1). 

The level 1 capabilities of the MDAS will be able to answer preliminary 
inquiries concerning the capabilities of the shuttle system, generating 
candidate event sequences for mission developed by the flight scheduler 
and the traffic model program, and performing cursory evaluation of these 
missions from a trajectory and operational standpoint. This level of 
analysis should discern some of the more obviously desirable and un- 
desirable features of each proposed shuttle flight and provide the 
following type of answers to management. 

YES: The shuttle has the capability (time, AV, etc.) to 

fly a specified mission. 

NO: The shuttle does not have the capability to fly a 

particular mission as specified. 

MAYBE: The MDAS needs to know more about the requirements 

and constraints for this mission, or a more thorough 
analysis is required before an answer can be given. 

Level 2 capabilities will be used to refine the conceptual plans 
developed in level 1. This level of support includes performing de- 
tailed analyses of the mission phases, assisting in the development of 
new onboard software and procedures, and developing detailed launch 
schedules, alternate mission plans, and contingency plans. This’ level 
of support would also assist in the establishment of crew training needs, 
real-time software requirements, and support procedures. 
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Level 3 capabilities will be used to verify that the plan developed 
by the other two levels can be flown by the shuttle and that it will 
satisfy most of the mission objectives. It will also be used to generate 
crew and ground support team training data, and complete the mission time 
schedule . 

Some elements of the level 2 and level 3 capability could be used 
to provide real-time backup support. The support that is provided, of 
course, will depend on the particular mission requirements and the degree 
of autonomy achieved by the shuttle itself. 

Figure 5-2 shows how the MDAS level 1 capabilities would be used to 
support the development of long- and short-range launch schedules and 
plans. First, the mission objectives, payload information, and system 
status are defined by management and the flight scheduler. Then the 
flight scheduler would allocate the payloads to a specific flight and 
develop a preliminary traffic model. The MDAS supports this effort, 
using level 1 capabilities, by performing a preliminary performance 
evaluation for each mission (blocks A and B). If the vehicle is incapa- 
ble of flying one or more of the desired missions, the payloads are re- 
allocated and a refined traffic model is generated. If it is capable, 
the analysis continues. 

The next function is to determine if any of the missions in the 
traffic model contains any unique or marginal phases (block C). A 
launch time is established for the missions which do not possess unique 
or marginal phases (block G). The missions which do possess such phases 
are evaluated in more detail in the MDAS (blocks D and E). If, after 
this evaluation, these missions are not acceptable, the traffic model is 
refined once again (block F). A launch time is established for the 
missions that are acceptable (block G). 


After each mission is assigned a launch time, the total launch 
schedule is evaluated for conflicts. If conflicts arise which cannot 
be resolved by the analyst, the traffic model is refined once again 
(block H) . If the launch times are then acceptable, a launch schedule 
is established and is presented to management for approval (block I). 

5-l* i + Requirements .- The primary requirements for such a subsystem 

are 

a. To support the development of long- and short-range shuttle 
launch schedules and the integration of payloads into definable 
missions 

b. To develop mission plans 
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c. To perform detailed analysis on critical, marginal, or unique 
mission phases 

d. To support payload development 

e. To generate new procedures (onboard or ground) for new missions 
or mission phases 

f. To develop simulation data for flight crew and ground support 
team training 

g. To develop real-time support data required by the flight crews 
(crew charts) or the ground support team 

h. To verify onboard software required for a particular mission 

i. To maintain and update the mission design and analysis infor- 
mation 

j. To perform mission planning support of any phase of a mission 

k. To evaluate any new or updated hardware 

l. To develop trajectories and mission profiles in any level of 
detail required for any mission or unique mission phase. 

5.1.5 Subsystem description .- The MDAS can best be visualized as a 
fully integrated Mission Planning Laboratory. Such a facility will con- 
sist of a set of interactive consoles manned by trajectory design spe- 
cialists, an integrated software system, and a common data base. This 
data base may be just one part of the larger VMMPS data base or a 
separate system tied to the larger one; but, in any case, the MDAS data 
will be updated every time the VMMPS data base is changed or expanded 
and will be accessible to the other elements of the VMMPS and vice 
versa. 

The software library in the MDAS will be comprised of two levels 
of capabilities - computational modules and segments. 

The computational modules will be the smallest elements in the 
library and will consist of things like powered flight models , target- 
ing models , coasting flight models , reference system transformations , 
planetary ephemerides, and so on. The segments will be composed of a 
group of these modules developed relative to standardized mission 
phases or activities (rendezvous, deorbit, deployment, etc.). Most of 
the modules and segments will be developed from a selected set of the 
simulation capabilities now possessed by MPAD and from the simulation 
capability developed during the shuttle development phase. All onboard 


26 


targeting and guidance software will be completely simulated, and all 
software will be integrated into one software system under the control 
of the VMMPS executive program. This will permit the user to use a 
limited set of the total system capability or any compatible set of 
the computational elements of the total software system. These modules 
and segments can be linked to do sequenced processing or can be executed 
alone for special applications. 

The software will be operable in' an online interactive or batch 
mode or in an offline batch mode. The primary users in the online inter- 
active mode will be the personnel in the VMMPS who have the responsibility 
of supporting the generation of schedules and plans and personnel of the 
flight operations support who have the responsibility for real-time com- 
putational. support. In the offline batch mode, the software in this 
subsystem will be used for performing detailed trajectory design and 
analysis tasks for the more unique shuttle missions or for analysis and 
evaluation of new hardware and software. 
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5.2 Flight Scheduler Subsystem (FSS) 


5-2.1 I ntroduction . - The flight scheduler subsystem is the inte- 
gration element of the VMMPS. It is the central planning and scheduling 
element of the VMMPS and supports the management and integration of 
launch, payload, and mission loads schedules. Other elements of the 
VMMPS, with the exception of the information management subsystem, are 
technical subsystems providing models and simulations of specific shuttle 
operations. Each of these subsystems provides the necessary data, evalua- 
tions, and so on for use by the FSS in the performance of its functions 
of supporting fleet scheduling and resource allocation decisions and 
cost trade-off studies . 


In normal operation, the FSS provides vehicle management personnel 
with a detailed overview of current and future status of shuttle opera- 
tions. It provides a means to evaluate the effect of changes or modifi- 
cations to the basic shuttle operations cycles, which provides quick 
response information, thus minimizing reaction time to changing events. 

The FSS is able to assist in the assessment of shuttle operations 
sensitivities to status changes by rescheduling activities and generat- 
ing alternative plans when status changes are introduced. This process, 
while supported by FSS software, will rely heavily on the planners de- 
cision making capabilities being in an interactive environment. 

5.2.2 Objective .- The purpose of the FSS is to assist in trans- 
lating NASA shuttle program directives into crew, vehicle, payload, 
logistics, launch, mission, landing, and resource requirements. These 
requirements are issued in the form of long- and short-range plans and 
schedules for all ground and mission sequencing activities required for 
support of each shuttle flight . 

5.2.3 Functions ■ - The overall function of the FSS is to provide a 
tool for generating integrated plans and schedules for the entire shuttle 
program, including launch, maintenance, payload integration and mission 
load operations. The FSS should be able to provide data to management 
for the evaluation of the cost impact on the shuttle program of schedules, 
plans, and resource implementation. To provide this information relating 
to schedules and plans, some of the specific functions to be performed 

by the FSS are as follows. 

a. Monitor status of VMMPS data base - The FSS should at all times 
be aware of changes in the VMMPS data base that might have an 
impact on flight schedules or operations planning. 
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b. Define mission objectives - The FSS will take multiple user 
requirements, payload data, priorities, and so forth, and, 
with a knowledge of shuttle operational constraints and guide- 
lines, define objectives of specific shuttle missions. Collect- 
ively, these missions will make up a traffic model which is 
evaluated by the mission design and analysis and other VMMPS 
subsystems. 

c. Construct flight schedules - The FSS will generate both long- 
and short-range flight schedules that reflect an integration 
of user schedule requirements, payload, buildup, vehicle main- 
tenance, and trajectory launch constraints. For a given number 
of shuttle vehicles , there will be conflicts in schedules be- 
tween user agencies. The FSS will identify these conflicts 
and assist in their resolution. With an awareness of the total 
problem through the other VMMPS subsystems the FSS will be able 
to use an iteration process to relieve these conflicts and 
arrive at flight schedules that are a feasible solution to the 
conflict . 

d. Integrates operation support plans - The FSS will support the 
development of integrated top level operations plans that re- 
flect a method for accomplishing program objectives as reflected 
in the flight schedule. By combining individual VMMPS ' subsystem 
functional plans, the FSS can assist in the formulation of the 
overall plan and create a feedback mechanism for review and 
evaluation of past performance. 

e. Analyze and forecast operations cost - The FSS will be able 

to translate shuttle program objectives and resulting schedules 
and plans into cost data. Cost tradeoff studies can be per- 
formed to determine feasibility of alternate plans and schedules. 
The FSS provides data for analysis of financial aspects of these 
plans and identify less obvious indications. For example, a 
request for an inventory change must be analyzed to determine 
if it provides an efficient use of funds. 

f. Determine resource and fleet utilization - The FSS will be able 
to assist in the assignment of specific vehicles and cargo loads 
to. each shuttle flight. Keeping track of the number of uses 

and current status of each vehicle and payload will be a function 
of other VMMPS subsystems, but the FSS must use these data to 
assign vehicles and payloads in an optimum manner with regard 
to total resource allocations and utilization. 

g. Forecast operations support requirements - In performance of 
the previous functions, the FSS will have available the soft- 
ware and data to assist in the analysis required to answer 
operational support requirement questions. 
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5 . 2.4 Description of current capability .- Presently, the initial 
core elements of the FSS exist in preliminary form and have been used 
to produce several shuttle mission models. Specifically, the payload 
loader and the resource allocation modules are already functioning and 
undergoing evolutionary changes and are expected to provide the more 
sophisticated models required by the VMMPS. The cost data module is 
in the conceptual stage of development . 

a. Automated payload - The payload loader module simulates the 
efficient combining of payload to be flown in the shuttle. 
Candidate payload pieces from various sources are integrated 
into a time line and traded off against each other using 
criteria such as weight, size, priority, mission compatibility, 
and schedule flexibility. The module attempts to accomplish 
this function in such a way as to minimize the demands in terms 
of flights, vehicles, payloads, and so forth. 

The payload loader assesses the compatibilities of all payloads 
against each other over the entire array of candidate flights. 

The solution sought is the assignment of each payload to a 
flight in such a way that all pieces will fit the area and per- 
formance restrictions of the payload kick stage. The payload 
loader, when completely developed, will allow studies and 
tradeoffs on the effects of payload changes on the traffic 
model and fleet scheduling to be made. A large array of vari- 
ables will have to be considered in the cargo loading capability. 
Among these are 

1. Optimal loading methods 

2. Performance characteristics of vehicles 

3. Priority definition system 

4. . Center of gravity effects of loading configurations 

5. Comprehensive and accurate data definition of payload 

6. Detailed down cargo requirements must be identified 

7. The effect of changing payload delivery dates must be 
modeled 

8. Mission design 

9. Automatic loading to incorporate all of the above 
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b. Resource allocation module - The resource allocation module 
assigns particular orbiter and booster stages, pads, and so 
forth to each mission. It uses vehicle, launch operations, 
and payload log data provided by the other VMMPS subsystems. 

The payload support subsystem will provide the earliest and 
latest times for each payload and the payload loader will 
determine payloads having common time intervals. A specific 
orbiter, booster, and pad is assigned to each load based on 
the earliest time associated with all loads. The number of 
loads that can be allocated depends on the distribution of 
the earliest and latest times, pad, booster, and orbiter turn- 
around times, mission duration, time interval between launches, 
the number of pads, orbiters and boosters available, and 
maintenance cycles and unscheduled events. In order to effect- 
ively schedule payloads and vehicles, considerable information 
about the status of each will have to be continuously updated 
and monitored. This implies, for example, that the vehicle and 
payload flight logs will have to keep track of where a particular 
stage is in its usage cycle. 

c. Cost data module - The function of providing cost data for 
management evaluation can be satisfied by including expected 
costing algorithms which evaluate the operations plans and 
schedules provided by the VMMPS. As a schedule or plan is 
formulated, the cost information could be output on request. 
Likewise, segments of a plan could be analyzed from a cost 
standpoint so that various alternate plans can be evaluated 
against each other . 
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5-3 Launch Operations Subsystem (LOS) 

5-3.1 Introduction .- The flight scheduling functions that are per- 
formed by the VMMPS will require a gross software simulation of the 
launch operations. Questions concerning . number, of pads, crews, and 
resulting cost for various flight rates can be evaluated by simple models 
of the operations. The effects that a single payload malfunction during 
checkout will have on the pending multi-payload mission will have to be 
evaluated. The decision of whether to launch with one dead payload or 
to delay and offload or change out a payload could be made if a simple 
model of the launch operations is developed for the VMMPS. 

The effects of launch anomalies become more significant as launch 
rates increase. These must be evaluated during the long-range fleet 
scheduling activity, and the resulting flight schedule should reflect 
these anomalies. 

5.3.2 Objectives .- The objectives of the launch operations subsystem 
are to evaluate long-range traffic models for cost effectiveness, using 
stochastic models where necessary. It will provide short-range evalua- 
tion of anomalies in the launch operations or of changes in program plans 
or priorities. The objectives can be met by providing simulation capa- 
bility for the period from mating to launch. This simulation, if in 
sufficient detail, allows the prediction of the status of launch system 
elements any time downstream with an accuracy acceptable to VMMPS re- . 
quirements. A means for imposing launch operations anomalies and failures 
for supporting planning tradeoffs may be necessary. At the same time, 
real-time status information will be supplied to the FOSS for operations 
monitoring. Consumables loads and subsystem performance information will 
be reviewed by the VMMPS when anomalies exist. 

5 . 3.3 Functions .- The LOS, a closed-loop simulation of a given 
activity period, will ascertain in a gross sense the preliminary feasi- 
bility of a proposed sequence of launch dates and will allow programatic 
changes to adjust to a dynamic situation during near-real -time planning. 
The subsystem will interface with the IMS for storage and retrieval of 
current status of data and detailed launch operations plans as developed 
by detailed models at the support facility. The subsystem may be accessed 
from any of the functional areas through the executive (fig. 5-3). It 
will be used primarily to support the launch operations , flight opera- 
tions, and flight scheduler areas, but it will also interact with the 
payload operations and vehicle operations subsystems to evaluate pro- 
posed schedules, to input probabilistic launch anomalies, and so on. 
Basically, this subsystem will relate the launch and launch facility 
recycle capability to mission planning. 
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5.3.4 Requirements The LOS will have the following requirements: 

a. Provide the flight scheduler with nominal predictions of launch 
operations , given a series of launch dates 

b. Provide flight operations with current status on the launch 
operations flow for upcoming flights 

c. Provide the vehicle support subsystem with trend and system 
status information based on checkout results 

These requirements can be met by the development of the following 
software packages: 

a. Cost tradeoff model 

b. Dynamic status data storage and retrieval 

c. Probabilistic simulation 

d. Facilities refurbishment processor; this may be satisfied in 
item b. 
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5.4 Vehicle Operations Subsystem (VOS) 

5*4.1 Introduction .- An onboard malfunction detection and fault 
isolation system will be required if the shuttle is to satisfy the 
operational readiness requirement. Moreover, system performance analyses 
(consumable analyses) cannot be performed as on past programs and should, 
in fact, be an integral part of any malfunction detection and fault isola- 
tion system. The depth of onboard systems performance analyses has not 
been decided; however, the maintenance (ground and onboard), malfunction 
detection and fault isolation, system performance, and trend analyses 
must all place requirements on the design of the systems so that appro- 
priate sensors can be planned during the design of the systems to 
satisfy all requirements. Much effort on Apollo systems performance 
evaluation could have been eliminated by implementation of appropriate 
sensors during the design stages. Therefore, it is assumed that the 
maintenance and systems performance requirements , both ground and on- 
board, will be integrated during the design phase. 

5*4.2 Objectives .- The objectives of the vehicle operations sub- 
system are to provide the overall planning system with sufficient infor- 
mation to accurately predict the vehicle utilization for both short-range 
and long-range planning. Maintenance cycles must be predicted, and the 
effects of both scheduled and unscheduled maintenance evaluated. Since 
the shuttle is a reusable vehicle, the systems performance will change 
from mission to mission. The 1^ of engines will vary and must be up- 
dated and the effects evaluated for future missions. Many systems will 
have similar inputs into the planning systems. One objective of this 
subsystem is to simulate these and evaluate the effects on mission 
planning. 

5*4.3 Functions .- The purpose of the vehicle operations subsystem 
is to use test data, design data, and flight data to determine during 
mission planning the predicted vehicle performance and maintenance re- 
quirements. This model will fulfill its purpose by making trend 
analyses on all appropriate system components and line replaceable units 
(LRU). The results of the trend analysis will be the prediction of 
system performance. The following systems will be analyzed by the trend 
indicator: 

a. Electrical power system 

b. Propulsion system 

c. Environment control/lift support systems 


d. 


Cryogenics system 
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e. Guidance system 

f. Auxiliary power unit 

g. Thermal protection system 

The data used to analyze the trends of the systems performance 
will be obtained through an interface with the information management 
subsystem through the VMMP system executive. These data, when used in 
conjunction with the system design, test data, past performance and 
trend data, and the simplified system performance prediction models, 
vill determine when operational limits will be reached and what their 
effects on future flight schedules will be. 

5 . 4.4 Subsystem description .- Other centers will have software 
models of the logistics associated with their prime areas of respon- 
sibility - launch operations, maintenance, and payload integration. 

The models will be complicated and detailed. The Manned Spacecraft 
Center must communicate with these models , which can be done by build- 
ing grossly simplified models in the VMMPS or accepting input constants. 
The following sections discuss the maintenance data, vehicle log, and 
system performance simulation of figure 5-4. 

5 . 4. 4.1 Maintenance: To evaluate the feasibility of proposed 

flight schedules, the maintenance turnaround must be simulated to some 
degree. Initially, flight schedules will be limited by maintenance crew 
proficiency. Their learning curve is simulated in present analyses. 
Eventually, the maintenance will be both driven by and will drive the 
flight scheduling, and project management will be required to evaluate 
proposed missions and maintenance impact. The maintenance model de- 
veloped for the VMMPS should satisfy the following capabilities: 

a. Define the time required for maintenance cycles 

b. Stochastic simulation of major events 

c. Learning curves for major events 

d. Major systems status update 

e. Unscheduled maintenance update capability 

f . 


Vehicle log update 
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With this simplified model, project management will be capable of 
making cost-trade feasibility studies and fleet scheduling decisions 
without time-consuming interface and review by other centers. The 
final schedule would then be reviewed by detailed simulation at various 
centers for final confirmation, but significantly different results 
should seldom arise. 

5- 1 +.H.2 Vehicle log: The vehicle log will contain past, present, 

and predicted information on each vehicle. Based on the current traffic 
model, total hours on each vehicle, maintenance projection, and systems 
utilization by serial number will be logged and modified as the schedules 
change from day to day and mission to mission. For example, actual heat 
loads on the thermal protection system will differ from the predicted; 
operating time on ACS thruster will vary; and, while original maintenance 
schedules are based on predicted system utilization, actual maintenance 
schedules may change. The vehicle log, therefore, will be updated after 
each mission. It will satisfy the following requirements: 

a. Past history of vehicle utilization 

b. Configuration status 

c. System identification by serial number 

d. Predicted modifications 

e. Predicted maintenance schedule 

f. Predicted systems utilization 

5. 4. 4. 3 Systems performance simulation: Onboard sensor information 

could be stored on magnetic tape and transmitted by high-speed data lines 
to MSC when the vehicle lands . These data should be sufficient to allow 
evaluation of critical system performance and to do sufficient trend 
analyses so that the predicted use of the vehicle can be validated. The 
simulation then could be updated during the maintenance, if system failure 
is noted. The system models in the VMMPS should be relatively simple 
and result primarily in trend analyses. Historical information by sub- 
system may be required in the data base for predicting accurate trends. 
This system shall satisfy the following requirements: 

a. Real-time update capability 

b. Simulate all critical systems for performance evaluation and 
trend analyses 

c. Interface with maintenance simulation on predicted subsystem 
maintenance 


d. 


Update vehicle log for system status 
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5.5 Payload Operations Support Subsystem (POSS) 


5 . 5 .1 Introduction .- Planning a particular shuttle mission begins 
with the definition of a payload and an expected launch date. A shuttle 
payload in this document includes the specific satellite or experiments 
(payload) and the attendant payload module and supporting equipment. 
Payload development, module production, experiment development, and' 
participation of the scientist/user must be scheduled so that integra- 
tion of payloads with the module, preflight preparation of instrumenta- 
tion and test specimens, preflight checkout and testing, and installation 
of the payload module in the shuttle will coincide with the scheduled 
launch date. In instances when the shuttle returns a payload or module 
to earth, the module will generally need to be refurbished and the pay- 
load updated. In instances when the payload or module contains stored 
data, experiment-peculiar instruments, and specimens, they must be 
removed, attended, and returned to the user in a timely manner. . 

5.5.2 Object ives .- The objectives of the payload operations support 
subsystem are to provide the VMMPS with the necessary information about 
shuttle payload operations processes. The VMMPS can then evaluate the 
feasibility of proposed flight schedules and plans . It should provide 
the VMMPS with simulated payload integration and handling, including 
time predictions, real-time status reports of payload flows, and an 
evaluation of payload compatibility with flight schedules and mission 
plans . 

Many components of shuttle payloads will be reusable. For example, 
the payload modules and supporting equipment , even payloads themselves , 
will be recycled. The POSS, therefore, must identify the payload com- 
ponents that are common to several missions, and evaluate the effect 
both of scheduled and unscheduled maintenance (just as must be done for 
the shuttle itself ) . 

Shuttle payloads may impose unique requirements on the shuttle 
systems. This will result in varying degrees of modification to the 
vehicle and systems, thus' affecting specific vehicle availability. 

5.5.3 Functions .- The purpose of the POSS is to model and maintain 
status data on payload operations and thus provide the following: 

a. An evaluation of payload compatibility with flight schedules 

b. Payload flow status, prediction, and an assessment of schedule 
impact 

c. An evaluation Of payload compatibility with mission plans 



d. Payload interface constraints 

e. Payload development schedules and predicted delivery dates 

f. Identification of common payload components between shuttle 
missions, status data on the refurbishment of these components, 
and predicted utilization 

g. An assessment of the impact of short-range, experiment or pay- 
load changeout and availability of alternate payloads 

5-5*4 Requirements .-- The POSS . will have the following general 
requirements: 

a. Access to the information management subsystem for storage and 
retrieval of status data from various elements of payload 
operations 

b. A probabilistic model of payload component development and 
deliveries 

c. A simulation of payload integration and handling flow 

d. A payload status log which contains past, present, and pre- 
dicted information on each payload component 

5-5-5 Subsystem description .- The payload operations facility 
should have detailed software models of the logistics associated with 
the payload integration, preparation, and refurbishment. The VMMPS, 
however, will have to communicate with these models by maintaining a 
payload data base and grossly simplified simulation of the payload 
integration flow. 

The proposed POSS is illustrated in figure 5~5- Principal internal 
VMMPS interfaces will be with the flight scheduler subsystem, the mission 
design and analysis subsystem, and the vehicle operations subsystem. 
External interfaces are with payload module manufacturing, user agencies, 
payload integration and installation, and payload refurbishment. Both 
external and internal interfaces will occur principally through the 
VMMPS data base under control of the overall executive. 

The basic POSS modules are the following: payload log, payload 

flow simulation, and payload development model. 
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5 -5* 5.1 Payload log: The payload log will contain past, present, 

and predicted information on each payload and payload module. Informa- 
tion on payloads will consist primarily of current development status 
and a payload integration flow history. These payload histories will 
enable refinement of the payload flow simulation models for those pay- 
loads and mission types that are repeatable over the long-range plan. 

5. 5- 5-2 Payload flow simulation: As perturbations to the payload 

integration flow occur, the feasibility of proposed flight schedules 
must be evaluated and both long- and short-range schedules must be 
altered. Likewise, the impact that proposed flight schedule changes 
will have on the payload integration flow must be evaluated. This 
simplified model will give project management the capability of pro- 
viding feasible fleet schedules without time-consuming and costly inter- 
face and review by each user agency and other centers. The final schedule 
can then be reviewed by appropriate centers with their detailed simula- 
tions for final confirmation. 

5- 5- 5-3 Payload development: This model (may be input constants) 

will be used to predict payload development cycle times for each payload 
class, to predict the availability of payloads for integration into 
short-range shuttle flight schedules and missions, and to understand the 
impact that schedule changes will have on payload development and user 
agencies. 

The payload log will contain payload development history and status 
data required for updates to the development model. The payload develop- 
ment model will provide delivery schedules and probabilities and pay- 
load interface constraints to the payload flow simulation. 



VMMPS 



I 


FIGURE 5-5. PAYLOAD OPERATIONS SUBSYSTEM 
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5*6 Crew Support Subsystem (CSS) 

5.6.1 Introduction .- Because shuttle missions are divided into 
different types, different shuttle crewmen will be trained for different 
purposes. Thus, certain crewmen will have specialized training and ex- 
perience for particular types of missions. (The term crewmen includes 
the payload handler, experiment operators, etc.). Since crews will be 
operating in an environment more similar to aircraft operations, the 
flight scheduling and crew scheduling functions will have to be closely 
coupled to insure that the right type of crew is available to satisfy 
the mission requirements of the flight schedule. 

5.6.2 Objectives The objective of the crew support subsystem is 
to provide the VMMPS with sufficient information regarding crew status 
to insure that the shuttle flight schedule is compatible with crew re- 
sources and constraints . 

5.6.3 Functions .- The crew support subsystem has three functions: 

a. Flight crew scheduling 

b. Maintenance of flight crew log 

c. Identification of training requirements (unique mission require 
ments ) 

This subsystem will provide an automated means for shuttle flight 
crew scheduling. An important aspect of this function is the evalua- 
tion and iteration of preliminary flight schedules in light of crew 
scheduling constraints. The constraints will be established at some 
later date but are likely to consider such items as 

a. Interval between assignments 

b. Training requirements 

c. Previous training and experience 

d. Accumulated flight time within a fixed period of time 

e. Flight duration 

f. Crew preference 

g. Availability of a backup crew 

h. Other established crew rotation guidelines 
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The subsystem will maintain a crew status log which will supply 
data to the crew scheduler and management about the current predicted 
status o-f individual crews and crewmen. The log will reflect such infor- 
mation as 


a. Experience and training 

b. Projected flight assignments 

c. Projected training schedules 

d. Periods of nonavailability 

e. Specialized capability 

Additional training requirements will be identified by comparing 
existing and projected crew proficiency and experience against the re- 
quirements of the flight schedule. 
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flight schedules 

• Provides prelaunch timelines for 
fleet planning purposes 

• Evaluates impact of "on pad" 
mission changes on launch 
schedule 

• Evaluates effect of launch 
holds 

• Insures that prelaunch and 
launch constraints are con- 
sidered In plans 

• Provides current and pre- 
dicted launch operations 
status 


Predicts turnaround tl«e- 

• ' ,n ? s for planning 
Evaluates Impact of maintenance 

Evaluates impect of schedule 

• ° n operations 

• IMl " t * n,n « data base 

tr,de *‘“d1es re- 
lated to maintenance for flight 
scheduling decisions ^ 


Batch Processor 


Melntenence simulation 


Cost data processor 


Launch operations simulation 


Launch operations status loq 


Cost processor 


Payload flow simulation 


Payload development model 
Cost data processor 
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5.7 Information Management Subsystem (IMS) 

5.7.I Introduction .- The information management subsystem can 
automatically provide data to any other subsystem as input for software 
computations or can operate in a storage and retrieval mode for direct 
user access to the data. The IMS will maintain the integrity of all 
data which the other VMMPS subsystems will draw upon to accomplish their 
respective management and planning functions. It will contain allocated 
sections for the storage of output plans, schedules, mission phase de- 
signs, and other information resulting from subsystem computations and 
decisions during the planning system operations. Some output will use 
a working storage area so that other subsystems will have subsequent 
access for refinement, redesign, or alternate approach analysis. The 
final output products, representing accepted plans, schedules , mission 
designs, and operations activity, will be saved in protected locations, 
which can be changed only by certain codes and after clearing the proper 
management channels . 

The stored data can be classified into several broad types. Within 
each of these types, some data will be frequently updated, such as the 
dynamic status of various shuttle refurbishment operations at the launch 
site; other data will be constant in nature, such as payload physical 
characteristics and management guidelines. The types of data include 

a. Payload characteristics 

b. Shuttle capabilities and configurations 

c. Maintenance operations 

d. Vehicle systems 

e. Plans and schedules 

f. Mission types and designs 

g. Cost application parameters 

h. Decision ground rules and tradeoff criteria 

i. Launch operations 

Each of the other subsystems of the VMMPS will have direct access 
to the IMS in a multiuser environment. Various application subsystems 
will have data sections which are peculiar to their function, while 
other data will be shared with other elements of the VMMPS. The IMS 
will be accessible by automatic calls from subsystem processors and 
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will be updated by processor- and man-initiated commands in a remote 
terminal or batch input mode. The IMS is thus very closely related to 
the other subsystems through various channels of data communication and 
through their command linkage to subsystem software. In accomplishing 
this linkage and providing channels of communication, the IMS will have 
a very complex executive processor linked to its data files. This pro- 
cessor will direct traffic in and out of the IMS and will maintain the 
data files structure. 

5 . 7.2 Objectives .- The information management subsystem is intended 
to provide the VMMPS with a central dynamic storage and retrieval system 
with multilevels of data protection. It will maintain formatted output 
storage of results from other software subsystem operations and storage 
for basic data describing relevant aspects of the shuttle vehicles and 
shuttle operations. 

5.7-3 Functions .- 

a. The IMS will primarily maintain, coordinate, and provide rapid 
access/update to an approved, verified, and highly structured 
set of resource data related to the space shuttle program. 

These data will be of sufficient detail to allow all mission 
designs, schedules, and resource assignments to be made, by 
using the various interactive subsystems of the VMMPS, within 
a response period consistent with the planned launch frequen- 
cies. To accomplish this, the IMS must contain resource data 
describing all aspects of shuttle operations, including booster, 
orbiter , space stations, launch, maintenance, mission design, 
management, support systems, and hardware/software development. 
All data will be monitored and their status maintained. 

b. Data will be acquired, structured, and stored continuously as 
the space shuttle program proceeds through its design, develop- 
ment, testing, and operations /support phases. During each 
phase, the IMS will maintain and provide access to data of the 
detail, required by the VMMPS. During all phases of the shuttle 
system design, the IMS will function as an exchange terminal 
for flow of information at various frequencies and in numerous 
formats between the VMMPS subsystem processors and the IMS, on 
one hand, and between the IMS and various users and the plan- 
ners on the other. 

c. The IMS will function as a singular centralized information 
system. It will be self-sufficient in its ability to supply 
the data needs of the subsystems calling upon it for infor- 
mation. All data requests from users, whether subprocessors 
or individuals, will have rapid response and accurate communi- 
cation, thus eliminating excessive time delays inherent in any 
noncentralized and unprotected data supply network. 



d. As much as possible the IMS will use automated file inversion 
and cross-file indexing for storage and for maximum economy 
and performance. The system will have numerous internal con- 
version and referencing capabilities; therefore, the number of 
structured files is small but without the danger of unprotected 
modifications of data content during usage and update of the 
data. 

e. The IMS will provide information files for maintaining sched- 
ules, operation plans, mission designs, inventory logs, and 
other data generated by the various VMMPS subsystems processors 
in the planning cycle. These data will become accessible to 
the other system elements as needed for sequential planning of 
missions and schedules. To accomplish this, portions of the 
subsystem-generated output will be used as working data for 
that system or processor only; other outputs will be placed in 
common data for use, dissemination, or additional analysis and 
tradeoff studies . 

f. The IMS will basically function on two levels. First, it will 
serve as a general question-and-answer system for obtaining 
visual or printed information from the system. The IMS can 

be used for generating reports and for item-by-item quizzing. 
Second, the IMS will support the flight scheduler and other 
subsystems as a formatted and automatic means of transferring 
data from storage to subsystem processors for planning com- 
putations. Initial capabilities to support scheduling, status- 
ing, and configuration control of the shuttle shall be provided. 
During the operations phase, this support will be broadened 
and will be adapted to rapid response and dynamic update and 
planning requirements. 

g. The IMS will provide all services to users and subsystem pro- 
cessors in a multiuser, re-entrant environment. It will be 
capable of supporting approximately 20 users simultaneously. 

This support will have no visible time delay from data acqui- 
sition. Data transmission and data processing will be as 
rapid as possible to enchance the man-in-the-system environment 
being used. 

5*7.4 Requirement s . - The IMS objectives and functions will require 
numerous software capabilities. Some of these requirements can be iden- 
tified, but detailed, subsystem-interrelated requirements will be avail- 
able only after the design phase is in progress. 
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a. The IMS will use standardized data accessing structures and 
English language user control for defining, updating, and 
accessing information. The IMS will correctly interpret a 
wide range of inputs, including precise formats for computer- 
generated requests and near-free-form user requests. Abbrevia- 
tions and symbols will minimize the size of input request streams 
while retaining phrase meaning. Format of the input may vary 
depending upon the application, but, in general, requests for 
data will be accompanied by the following: 

1. User and subsystem terminal identification 

2. Inquire, update, or computational mode _ 

3. Data file access pointers 

4 . Data requested or to be input as update 

5. Processing required before display or other output 

6. Output specifications or options 

b. The IMS must be able to save data at specified intervals and 
restore the data in case of hardware or software failures. A 
transaction log will be maintained with the capability of re- 
storing the data to any transaction point until the log is re- 
leased. 

c. A security system will be required to determine who will be 
allowed to update and access certain portions of the data. 

Since different individuals may be responsible for different 
portions of the data, the security should allow for securing 
individual elements of the data as well as the entire data 
base. The security system will protect any of the following: 

1. Individual data items 

2. Logical groupings of data items 

3. Subsystem characteristic data and output 

4. User commands 

This protection will include security updates both on data and 
on access to the data. 
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d. To support an English-language-oriented syntax, the IMS will 
provide capability to distinguish various types of words, 
including 


1. 

Commands 

2. 

Names 

3. 

Connectives 

4. 

Restrictors 


(a) 

Equal to 


(b) 

Greater than 


(c) 

Less than 


(d) 

Not 


(e) 

Combinations of the above 


e. Data access, update, and retrieval requirements will include 

the capability to accomplish the following actions. 

1. The IMS will use related storage, so that the user will 
not be required to input the same data more than once when 
the data or functionally dependent data exist in several 
locations . 

2. The system will create and verify data using data within 
other files. 

3. The user will be allowed to obtain any subset of data within 
the data base by the use of qualifiers and selection criteria. 

4. The system will automatically generate and store current 
data when items are updated. 

5. The system will, support terminal or batch input loading in 
both free, English-type formats and fixed field format. 

Inputs from terminals will allow the user to add new items 
to the data base; to change, delete, or reformat items con- 
tained in the data base; and to create relationships between 
data elements in the system. The system will be able to 
bulk load data from files, tapes, or from drum into the data 
system. This capability will be used for data transfers 
from other organizations to the IMS and for processor-to- 
processor transfers within the VMMPS . 
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f . The IMS will be required to provide a useful set of tutorial 
and system status support to aid the user in accessing the 
system and in using its capabilities correctly. This support 
will include the providing of various progress reports, request 
formats, terminal usage descriptions, data file update trans- 
action logs, available output formats in the system, subsystem 
usage instructions, and distribution of data requirements. 

g. The IMS will support various formats for output of data. In 
general , most output will be predefined and referenced in the 
request or implied by the type of operation being done. However, 
format specifications at the time of request will be allowed 

and guidelines for that formatting provided. 

h. The IMS will provide certain software which will allow some 
conventional postprocessing of data being brought out of the 
system. Typical of these operations is the ability to alpha- 
betize, count, total, sequence by some parameter value, and 
so on. 

i. The IMS will provide executive software, whereby subsystem, 
processors may automatically access and update the IMS in the 
normal functioning of the VMMPS during all phases of planning. 

5-7-5 Basic elements .- In fulfilling the software requirements 
which have been identified, several processor elements can be discerned, 
at least at a functional level. Other software may be needed, and some 
of the functions may be satisfied by software external to the IMS: how- 
ever, these software elements will be required either internal to or as 
support elements for the IMS: 

a. An input validation processor - To examine buffered inputs 
for data completeness, valid source codes, proper format, 
correct storage pointers, and receipt on acknowledgement input 
back to the sources. If errors in input are detected, the 
processor will explain the error to the user and advise him of 
corrective action. 

b. An input routine processor - To direct traffic within the IMS 
and to properly route requests from various subsystems to the 
appropriate IMS software or data locations. 

c. A file management processor - To accept the verified input 
codes and parameters , to form data file control commands , and 
to file linkage indexes and pointers. It will then execute 
the update by access and location of the data being specified. 
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d. A request processor - To satisfy all commands for data retrieval. 
It -will examine the request from the data input routine proc- 
essor and establish control parameters. It will then perform 
information retrieval, processing, and distribution to other 
processors for further formatting and usage. 

e. A tutorial processor - To assist the user in responding to error 
conditions from the input routine processor and other processors 
providing diagnostics. It will also provide general system 
usage guidelines and input/access mode capabilities. 

f. A storage processor - In conjunction with the file management 
processor, to structure, format, link, edit, index, position, 
audit, and execute the additions and changes to data. It will 
be responsible for interpreting the various security and 
hierarchy codes which will be used. 

g. An information processing processor - To accept the data from 
the request processor and assist that processor in satisfying 
the logical and comparative requirements of the original re- 
quest. Once data is obtained which meets the input requests, 
it will be routed to the format and distribution processor. 

h. A format and description processor - To accept the data which 
has been retrieved and format it to meet the requirements of 
various subsystem processors or direct access users who initiated 
the request. It will then route the data to subsystems, pro- 
cessors, terminals, input/output devices, and IMS internal files 
in the final execution of the input request. A transaction log 
will be kept at this point, and all appropriate subsystems will 
be polled for a go-ahead for data transmission. 
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OTHER PROGRAM OFFICES 


• Defines payloads 

• Establish* priorities 

• Approves lonq range plans 

• HaVes budqet related decisions 

• Provides user interface 


n 


• Provides Interface, direction - 

and coordination for other • 

space program supported by the _ 

Space Shuttle ■ 



fLEET MANAGEMENT 

• Maintains VMMPS data base 

• Defines mission objectives 

• Constructs flight schedules 

• Integrates operations Support 
plans 

• Monitors and controls operations 
progress 

• Analytes and forecasts operation 
costs 

• Integrates logistics planning 
and control 

• Determines resource and fleet 
utilization 

• Forecasts operations support 
requirements 



folSStOM DESIGN 


* Performs mission evaluation 

* Evaluated the flight schedule 
relative to trajectory consider- 
ations 

* Designs Individual missions 

* Performs trajectory and maneuver 
analysis 

* Maintains the. mission design 
deta base 

* Provides real-time contingency 
flight support 

* Generate ere* training data 

* Generate real-time support data 

* Define and Varlfy onboard software 

* Develop flight procedures 

* Determine net wort . ATC, and land- 
ing requirements 



ORBITAL OPERATIONS 

* Maintains log of freefly- 
Ing payloads 

* Oevelop payload related 
flight procedures 

* Insure that flight schedules 
are properly servicing exist- 
ing free flying payloads 

* Evaluate compatibility of 
Inflight payload operation with 
mission plan 

* Predict payload ground support 
requirements 

* Monitor f reef lying payload status 

* Evaluate schedule change on cri- 
tical payload support roqviraaents 



|REM operations 

* Mites crew, assignments 
’ Coordinates crew training 
requirements 
' Evaluates flight plans and schedule^ 
relative to crew considerations 
’ Develops crew procedures 
' Evaluates Impact of schedule 
changes on crew requirements 



• Evaluates payload timeline 
compatibility with flight 
schedules 

• Evaluates payload compatibility 
with mission plans 

• Assesses payload Interchange- 
ability and modification 

• Monitors and predicts payload 
status 

• Maintains payload related data 
base 

• Predicts payload servicing re- 
quirements 

• Establishes experiment priori- 
ties 



VEHICLE OPERATIONS 


• Perfprms subsystem performance 
prediction and trend analysis 
relative to flight planning 

• Maintains the Vehicle Log 

• Monitors and predicts vehicle 
status 

• Evaluates vehicle configuration 
compatibility with mission plans 

• Assigns vehicles to specific 
flights 

• Evaluates Impact of flight sche- 
dules on vehicle operations 


LAUHCH OPERATIONS 

• Evaluate launch consid- 
eration compatibility *1th 
flight schedules 

• Provides prelaunch timelines for 
fleet planning purposes 

• Evaluates Impect of 'on pad’ 
mission changes on launch 
schedule 

• Evaluates effect of launch 
holds 

• Insures that prolaunch and 
launch constraints are con- 
sidered in plans 

• Provides current and pro- 
dieted launch operations 
status 


MAINTENANCE OPERATION 

• Predicts turnaround tlme- 
lines for fleet planning 

• Evaluates Impact of maintenance 
requirements on flight schedule 

• Evaluates Impact of schedule 

• £ h ?" 9# ! on ■ <1fl tenence operations 
Maintains maintenance date base 
Performs cost trade studies re- 
lated to maintenance for flight 
scheduling decisions 



Vehicle Management and Mission Planning System 


Planning Functi< 
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5.8 Flight Operations Support Subsystem (FOSS) 

5 . 8 .I Introduction .- The flight operations support subsystem is 
an integral part of the VMMPS. 

The primary goal of the flight operations support subsystem as 
adopted for this proposed system is to reduce the ground support activity 
to a minimum. The elements that will- affect the level of ground support 
required during a shuttle mission are 

a. Degree of shuttle onboard autonomy 

b. Operational flight philosophy 

c. Standardization of flight profiles and procedures 

d. Crew proficiency and training 

e. Nature of the individual mission 

f. Support software system 

g. Stage of evolution of the shuttle from development program to 
operational status 

The most important of these is the degree of onboard autonomy 
attained by the operational shuttle vehicle. Even for a highly auto- 
nomous vehicle, certain ground support functions will have to be pro- 
vided. The shuttle, however, will perform on board many tasks currently 
done on the ground, and many other current tasks will probably not be 
performed to the degree they are today. Of the remaining tasks, those 
which cannot or should not be performed on board for whatever reason 
will be relegated to the ground support element. 

A reasonable flight philosophy for the operational shuttle would 
be to accomplish the primary mission objectives of each specific flight. 
For example, if a failure of an onboard system occurs during the course 
of a flight which jeopardizes the success of the mission, the standard 
procedure might be to terminate the mission and return to earth. The 
affected mission objectives could then be rescheduled on a later flight. 
Such an approach to shuttle utilization would be characterized by 

a. Little or no alternate mission planning 

b. Onboard evaluation of the system status 

c. Decisions made on board as to what flight objectives 
to try to accomplish 
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d. No significant deviation from flight plan 

e. Lower level of ground support required 

As in the mission design function, a key element for reducing 
ground support requirements is the standardization of flight profiles 
and flight procedures relative to mission type and common flight phases 
and events. This standardization coupled with a high density flight 
schedule will allow more routine flights , with individual crews becom- 
ing more proficient in specific types of missions. This would lead to 
fewer requirements for flight-crew-related support as the shuttle pro- 
gram progresses. 

In general, then, the factors which have an effect on the degree 
of flight operations ground support should decrease as the program 
matures. In fact, the requirement for ground support should reach an 
almost static level during the early stage of operational phase. 

5-8.2 Objective .- The FOSS, as envisioned in this report, should 
provide the shuttle with all normal ground software support required 
for interfacing with the real-time operation during the flight phase of 
a shuttle mission. The subsystem would be integrated into the VMMPS so 
that it can use the capability of other subsystems as required. 

5.8.3 Functions .- To keep the majority of the inflight operations 
on board the shuttle, the normal flight operations ground support for 
the operational phase have been reduced to five major functions. 

a. Flight contingency support 

b. Network interface and communication 

c. FAA and air traffic control interface 

d. Tug/kick stage support 

e. Real-time experiment and payload support 

The interfaces for these functions are depicted on figure 5-6. 

More complex, unique, or very costly missions may require a higher 
level of ground support than the standard-type missions. For such 
missions, the usual ground support activity could be augmented by ele- 
ments of the mission design team who are specially qualified in the 
type of support required. In this case, the FOSS could be augmented by 
the MDAS to provide additional capability where required. 
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If a serious problem occurs during flight which cannot be handled 
on board, the FOSS would be capable of providing assistance through its 
own software and through the MDAS. The requirement for such assistance, 
however, should be infrequent if a flight philosophy of return-and-try- 
again is adopted as the governing procedure for such inflight problems. 

During the flight test and qualification phase, the ground support 
activity would consist mainly of evaluating and verifying all onboard 
systems and vehicle performance in a manner similar to the present 
Apollo system monitoring function. In fact, the ground-based flight 
operations activity is likely to base a large part of the test activi- 
ties on real-time engineering evaluation. As the shuttle becomes 
operational, the monitoring function of the vehicle systems should 
diminish to a level compatible with the degree of shuttle onboard auto- 
nomy and the flight philosophy. 

5. 8. 3.1 Flight contingency support: When a contingency situation 

occurs, the FOSS would assist to the degree required by the nature of 
the specific problem. The action taken may range from the coordination 
of an early landing to the coordination of a crew rescue mission. Some 
of the flight contingency support functions are 

a. Coordinate landing activities for early deorbit 

b. Computation of orbiter maneuvers 

c. Plan and direct crew rescue missions 

d. Launch abort support 

5. 8. 3. 2 Network interface and communication: As envisioned by 
this report , the FOSS would provide the ground support interface with 
the network for the following functions: 

a. Tracking data utilization - Tracking data from the tracking 
network would be used to generate ephemerides for the orbiter and other 
vehicles and targets related to a specific flight. These data could 

be used to provide site acquisition information for communication re- 
quirements and to evaluate the trajectory if required. 

b. Telemetry data utilization - If required, the subsystem could 
be capable of receiving and processing telemetry from the tracking net- 
work for use in updating system performance. 
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5. 8 . 3. 3 FAA and air traffic control coordination: Such a sub- 

system could have the responsibility for coordinating all projected 
schedules with the FAA and air traffic control. These activities could 
include 

a. Alerting ATC of flight schedule status and changes which may 
have an effect on the current landing plans 

b. Requesting landing clearance from ATC, alerting the landing site, 
and coordinating landing plans in the event that the nominal 
flight plan is altered 

5 . 8 . 3 . k Tug/kick stage support: How much of the capability for 

providing computational support for tug/kick stage operation will reside 
on board the shuttle is currently not clear. At times, however, ground 
control of the tug would probably be desirable or even required, such 
as during interplanetary missions. For such support, this subsystem 
could provide the following functions: 

a. Trajectory determination 

. a 

b. Targeting and maneuver planning 

c. Acquisition and coverage computation 8, 

5.8.4 Requirements .- The specification of detailed requirements 
and capabilities of the FOSS is premature at present. This subsystem 
will not be immdeiately required and will have an evolutionary develop- 
ment. Much of its capability will be a direct outgrowth of the MDAS 
and of the nature of its real-time experiment and payload support role; 
however, many of the basic characteristics and requirements for the 
subsystem can be currently defined in general terms as follows: 

a. Support multiple ongoing missions 

b. Require a minimum of personnel during normal operations 

c. Be able to support the shuttle flight test program in a cost- 
effective manner 


a Software capability to be used may reside in the MDAS. 
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d. - Provide automated training aids for FOSS personnel 

e. Assist in the coordination of all flight support through inte- 
grated linkup with other software elements of the mission 
operations management and planning system 

f. Accept and use tracking data to generate ephemerides for the 
orbiter and any other designated orbiting vehicle 

g. Monitor the launch phase so as to provide support in the event 
of launch abort 

h. Support inflight modification of premission plans 

i. Provide backup maneuver computation and targeting as required 

j . Generate entry and landing information and plans which are 
adequate for the needs of the ATC for landing clearance and 
area air control and transmit such data to the ATC 

5.8.5 Subsystem descriptions .- Figure 5-6 depicts the interfaces 
between the FOSS and other elements of the shuttle support system. 
Figure 5-7 depicts a gross concept and structure for this software 
subsystem. Not all elements shown in figure 5-7 may be required to 
support a specific flight. The degree to which these elements are 
used will depend, in a large part, on the degree of shuttle vehicle 
autonomy. 
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N°te s: A Dashed Line Indicates That The Software Capability To Be Used 

Necessity is Dependent on May Actually Reside In Mission 

Level of Shuttle Design Subsystem 

Autonomy 




(b) Tracking data processing 

Figure 5-7. Flight operation support software system-Continued 
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6.0 SYSTEM DEVELOPMENT 


6.1 Introduction 

The development of the VMMPS will he both phased and evolutionary. 

As experience has proved, the development of such a large system should 
be flexible enough to respond to major, requirements changes. Such a 
development effort , moreover , must smoothly reflect the ongoing education 
of the designers. For example, over several years, the designers will 
advance in the state of the art of the system component disciplines 
(scheduling, e.g.), but will also make some adverse feasibility deter- 
minations concerning planned capabilities. No initial, hard-and-fast 
shuttle VMMPS design will exist; rather, the design will be generated 
and solidified in stages. 

This section presents the basic system concept and lays out a 
tentative development plan. This tentative development plan stresses 
flexibility, and is concrete only in the initial phase of development. 

The following development plan reflects the considerable experience 
that the MPAD has had in software development and systems design (i.e., 
the formulation and systems design of the Real-Time Computer Complex and 
the Mission Operations and Planning Schedule). The shuttle VMMPS develop- 
ment plan will consist of these phases: 

a. Gather and generate system requirements 

b. Design of a bench program prototype planning system 

c. Implementation of the bench program prototype planning system 

d. Generation of operating system concept 

e. Utilization of prototype system to test system concepts and 
carry out preliminary shuttle planning 

f. Design of the operating system 

g. Implementation of the operating system 

Each of these phases will be discussed in the following sections. 
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6.2 Gathering and Generation System Requirements 

Requirements will be generated by potential users, including MPAD, 
the shuttle program office, other MSC organizations, and other NASA 
centers engaged in shuttle activities. In building a system of this 
proposed complexity, the compilers and documenters of requirements must 
work in an environment of daily contact with the system designers. As 
the prime system design authority and system user, MPAD would coordinate 
the compilation and documentation of system requirements. 

During 1972 MPAD will informally solicit requirements from all 
potential system users. Those informal requirements will be compiled 
and will form the basis formulating a system concept in 1973. While 
the informal requirements are being gathered, a procedure will be evolved 
for the formal solicitation of detailed requirements, for the submission 
of formal requirements , for the approval of requirements , and for the 
documentation of requirements. In conjunction with the system designers, 
the requirements compilers will establish schedules for requirements 
documentation milestones. Initial requirements will subsequently be 
modified and expanded; hence, the function of gathering and coordinat- 
ing requirements must continue throughout the design phase. 
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6.3 Design of a Bench Program Prototype Planning System 

Several considerations indicate the need for a rudimentary proto- 
type shuttle fleet management planning system. 

a. An early capability to perform some shuttle planning is needed. 

b. Some of the software modules 'developed for the bench program 
would be integrated into the later system. 

c. The exercise would be very educational for the designers of 
the followon system. 

d. Problems encountered and ideas generated in designing the 
prototype system will feed back into requirements generation 
and modification. 

Some components of the prototype system already exist within MPAD. 
The design process would include extending the capabilities of those 
tools, adding other tools, and integrating all components into a single 
shuttle planning bench program. 

At a minimum, the prototype system would include the following 
components : 

a. Shuttle, facilities, and payload data base and data retrieval 
system 

b. A payload loading analyzer which generates compatible payload 
groups (candidate mission) 

c. A resources allocation capability which generates an assignment , 
of vehicles and facilities to missions 

d. The capability to stochastically model shuttle operations from 
launch to launch 


e. Mission design and analysis capability for mission-type evalua- 
tion 



71 


6.1+ Implementation of the Bench Program 
Prototype Planning System 

The prototype design must he implemented "both because the capability 
of doing preliminary shuttle planning is needed and because the actual 
implementation exercise will uncover design errors and prevent the du- 
plication of those errors in the later system design. In addition, an 
operating prototype system is needed to carry out validation of software 
modules which will eventually be implemented into the fiftal system. The 
bench program will be mainly an inhouse MPAD project, and its implemen- 
tation will provide vital education to the MPAD personnel who will be 
implementing and monitoring the more complex final system. It is pro- 
posed that the prototype system be implemented into the current facilities 
of the MPAD Mission Planning Laboratory. 
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6.5 Generation of Operating System Concept 

Inevitably, the initial informal requirements submitted by the 
potential users of a shuttle VMMPS will assume or propose several 
different concepts of the system configuration (e.g. , organizational 
interfaces, lines of authority, software capabilities, computer hard- 
ware, and system operating characteristics). A period of time will be 
allocated to the analysis of several possible configurations. In con- 
junction with the shuttle program office, the MPAD will evolve an over- 
all system concept which will subsequently be used as a baseline for 
the detailed system design. The resultant system concept will identify 
the following items : 

a. Organizational interfaces in the operation of the VMMPS 

b. Organizational responsibilities for levying requirements 

c. Electronic interfaces between centers involved in shuttle 
operation 

d. Computer hardware capabilities 

e. General operating characteristicst of the system (e.g., MOCR 
environment ) 

f. General software capabilities (e.g., payload integration, 
mission definition, resource allocation) 

g. General guidelines as to the utilization of existing MSC 
computer facilities 
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6.6 Utilization of Prototype System to Test System 
Concepts and Carry Out Preliminary Shuttle Planning 

While the overall system is being designed and implemented, the 
bench program shuttle planning system will be used by MPAD to support 
ongoing shuttle planning. The MPAD will be supporting the shuttle 
program office by generating shuttle traffic models, by performing 
fleet-sizing studies, by analyzing requirements for shuttle facilities, 
by performing analysis on the several mission types, by generating 
preliminary flight schedules , and by performing other studies as re- 
quested. By using the prototype system, MPAD will be able to test 
operations modeling and planning concepts. The experience gained in 
the practical utilization of the prototype system will be an invaluable 
aid for generating system requirements and designing the overall 
system. 



6.7 Design of the Operating System 


Definition of the detailed specifications of the VMMPS will tenta- 
tively start in 197** and will be approximately a 2-year effort. Accord- 
ing to MPAD experience in the design of large systems, requirements 
modifications, clarification, and expansion will frequently interrupt 
and redirect the system design. Too many requirements changes during 
the design phase can cause significant development cost overruns and 
cause significant slips in the delivery of the operating system. To 
minimize this impact, the design phase for the system will not begin 
until after a lengthy requirements gathering, requirements analysis, 
and the generation of an overall system configuration concept. 

During the design phase, MPAD and possibly other NASA organizations 
will formulate detailed specifications for the system. Among these 
specifications will be the logic and equations for modeling the different 
aspects of shuttle operations, detailed interface specifications be- 
tween the various software modules , display format specifications , and 
user-oriented input specifications. The result of the design phase will 
be a document or series of documents that will specify to the system 
implementors the detailed formulation of the software portion of the 
system. 
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6.8 Implementation of the Operating System 

The system will be implemented either by the system designers or 
by contractor personnel whom the designers will monitor. Since several 
years are provided for requirements gathering, for generating a system 
configuration concept, and for designing the prototype system, the 
system implementation ef fort ■ should not be significantly interrupted by 
requirements changes or major redesign. The implemented system will be 
tested, verified, and delivered as an operating system by the beginning 
of 1978. 
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